Bug: Callbacks dropped on retry
Summary: onTaskCompleted unconditionally removes callbacks from the maps on
RETRY. When the task eventually succeeds, callbacks are gone. Also fires
the
failure callback prematurely on 401 before retry.

What is the solution here? there can only be 1 callback at a time, if multiple calls fail we would override them. Also if there is a 401 there is a failure, independently if it retries or not. For example a tracking should not have a callback waiting for it for something to happen, if it tracked it does not really matter when

#: 4
Bug: Negative exponent in getNextRetryInterval
Summary: In the primary retry path, retryCount is incremented to 1 before
getNextRetryInterval is called, so it's fine. But in edge paths like
queueExpirationRefresh's catch block or checkAndHandleAuthRefresh,
retryCount can still be 0, giving exponent -1 and halving the interval.

This is the behaviour we always had, i think it is intended, we can cut a ticket for a fix if you think it is necessary

#: 5
Bug: Thread-unsafe authTokenReadyListeners
Summary: Plain ArrayList with no synchronization, accessed from multiple
threads. The snapshot copy in notifyAuthTokenReadyListeners doesn't protect
against concurrent modification during copy construction.

This should not really happen anywhere since we only have 1 call place, but i can make the fix as it is a simple one

#: 7
Bug: updateFromRemoteConfig dead code
Summary: Never called from production code. The remote config parsing only
reads KEY_OFFLINE_MODE and KEY_AUTO_RETRY, never endpoint classification.
The method exists and is tested in isolation but never wired up.

This is intentional, i can rename the function but it is just a placeholder if we get this list to be dynamic at some point

#: 6
2. setAuthState has a TOCTOU race (IterableAuthManager.java:109-114). The
read of this.authState and subsequent write are not atomic — two threads
could both read INVALID, both transition, and both fire notifications.
Consider making setAuthState synchronized.

The duplicate notification scenario requires two threads to both read INVALID
simultaneously and both transition to a non-INVALID state. In practice:

• handleAuthTokenSuccess sets UNKNOWN (token obtained)
• setIsLastAuthTokenValid(true) sets VALID (request succeeded)

These happen sequentially — you get a token first, then make a request, then
it succeeds. They can't race because the request can't succeed before the
token is obtained.

The only realistic "race" would be two simultaneous handleAuthTokenSuccess
calls, but requestNewAuthToken is already synchronized and has the pendingAuth
guard preventing concurrent token requests.

Worst case if it did happen: onAuthTokenReady() fires twice, which calls
runNow() twice, which is idempotent (it just posts a message to the handler,
and processTasks() handles an empty queue gracefully).